Re: a point is being missed

Sam Hartman (hartmans@MIT.EDU)
Sat, 4 Nov 1995 00:09:45 -0500

>>>>> "hobbit" == hobbit  <Hobbit> writes:

    hobbit> Why in all this telnetd flap has nobody mentioned that
    hobbit> /bin/login should be relinked STATICALLY?  That at least
    hobbit> defers the LD_* class of problem until after login has
    hobbit> done the setuid and exec, but still leaves things like IFS
    hobbit> passed to scripts.

        This point has been mentioned to me several times, and I've sort of publically ignored it because I don't consider it particularly valid.

        It is an acceptable temporary fix to the problem, and if you
have source to login but not telnetd, by all means use it.

        I really hope, however, that vendors don't start linking login
statically unless they start shipping source with their OS.  This
makes it impossible to fix bugs like syslog(3) by patching shared
libraries.

        In addition, depending on linker features like static binding
is bad policy; to the extent that it is possible, programs should be
secure, independent of any build procedure or enhanced security
features of a particular OS.

        I certainly think the idea of statically linking all network
applications is a bad idea.  Most network applications don't call
exec() so the libary issue is not likely to matter.  Of those that do,
only httpd, telnetd, to a limited extend rlogind, and possibly a few
others accept environment variables.


        Besides, as you hint, the potential for trouble is much
broader than LD_*; any environment variable used by libc could be a
potential target.  I think that this entire problem stresses the
importance of clearly defining the interface between trusted programs
like login and their users.  If the documentation for login mentioned
the dependence on LD_*, the assumption that -f was valid if the
uid==0, etc, several security holes over the past few years would have
been discovered and fixed much sooner.  I understand that issues like
LD_* are implicit in any dynamic executable, but I argue that good
documentation in login would clearly point out to implementers of
programs that call login how to use it without violating its
assumptions.

--Sam


    hobbit> Still, my own rule of thumb is that any binary that talks
    hobbit> to the net, handles inbound connections, handles
    hobbit> authentication, etc ... should not be depending on shared
    hobbit> libs.  It's well worth the miniscule disk space hit.
    hobbit> Vendors, LISSEN UP.


    hobbit> _H*